feat(committor): send settlement transactions with v1 - #1744

V1 transactions carry compute budget settings in the message config rather than through Compute Budget program instructions. The committor v1 path was still prepending those instructions, which made the serialized transaction larger than necessary and bypassed the new v1 config fields.

This updates the v1 assembly path to:

- serialize priority fee, compute unit limit, and loaded account data size limit in the v1 message config

- derive the v1 priority fee from the existing micro-lamports-per-CU price and task CU limit using Solana's rounded-up fee calculation

- assemble v1 messages from the settlement instructions plus the optional uniqueness noop, without v0 compute-budget instructions

- keep the existing v0 compute-budget instruction path unchanged for fallback transactions

Update the tests after the committor no-ALT path started producing v1 messages instead of v0 messages.

The strategist cases that are meant to force buffering now use payloads that exceed the v1 wire limit, and the stale single-stage ALT expectation is removed because ALT fallback is already covered by the lookup-table strategy test.

The preparator tests no longer compare v1 output against synthetic v0 messages. One no-ALT test asserts the v1 prepared-message variant, while the buffer-oriented tests keep their buffer completion assertions.

Add focused unit coverage for the custom v1 pieces: message config serialization order and priority-fee rounding.

The local v1 message shim serializes several fields with fixed-width protocol encodings, including the account-key count, instruction count, instruction account count, and instruction data length. The previous validation only checked the top-level counts and instruction data length, leaving some malformed messages to be serialized with truncated lengths or invalid indexes.

Tighten Message::validate() so it rejects invalid v1 structures before signing or serialization:

- enforce the protocol limits for signatures, account keys, instructions, per-instruction account refs, and instruction data

- reject impossible header/account-key layouts

- reject duplicate account keys

- reject invalid program and account indexes

- reject attempts to invoke the fee payer as the program

Add focused unit coverage for valid messages and the important invalid cases, including oversized instruction account lists that would otherwise truncate to u8 during serialization.

V1 settlement transactions can fail for structural reasons, not only byte size.
For example, a transaction may exceed the v1 static account-key cap while still
being a valid candidate for the existing v0 + ALT path.

The previous strategy optimized tasks into buffer deliveries before trying ALTs.
That meant a task set that only needed lookup tables could still pick up buffer
prep/cleanup work first.

This changes the strategy order to:

- preserve the original tasks while probing the v1 shape;
- use v1/no-ALT when it fits;
- try v0 + ALT with the original tasks before introducing buffers;
- only use the buffer-optimized tasks as the final payload-size fallback.

The tests now cover the current v1 boundary dynamically and include a regression
case where a key-count overflow falls back to v0 + ALT without buffering.

Propagate final transaction assembly failures through PreparatorResult instead
of panicking after delivery preparation.

Use the prepared message's instruction layout when classifying settlement
errors, and use the matching strategy layout during single-stage and two-stage
recovery. V1 carries compute budgets in transaction config, so its tasks start
at instruction zero; v0 still prepends two compute-budget instructions.

Keep the original instruction index in diagnostics and share the v0 budget
instruction count with assembly to prevent offset drift.

Agave 4.2.0 accepts the larger v1 transactions, exposing an undersized
loaded-account budget and test assumptions inherited from the old packet
limit. Correct these integration failures while preserving settlement
assertions and loader-v4 coverage.

The DLP API estimates its program data at 350 KiB, but the deployed test
program data occupies 464,837 bytes. V1 now enforces the loaded-account
limit in its transaction config, so inline transactions fail with
MaxLoadedAccountsDataSizeExceeded before they can execute. Reserve at
least 1 MiB for DLP program data once per transaction, after removing
duplicate program estimates. Retain per-task account budgets and the
loaded-account cap; add no RPC calls or hot-path allocations.

Keep the cloning and chainlink integration shards on Agave 4.0.3. Their
loader-v4 deployment instructions fail with ProgramAccountNotFound on
4.2.0 because that runtime removed the loader-v4 builtin. Support a
per-shard runtime override, leaving the other shards on 4.2.0 for larger
v1 transactions. Preserve the SBF build pin and disabled fail-fast.

Update small-bundle, mixed-intent, and 637-byte order-book strategy
expectations to DiffArgs. These transactions now fit inline in v1.
Preserve account-data, lamport, owner, and settlement assertions, along
with the large order-book cases that still exercise buffered delivery.

Allow transaction version 1 in both committor diagnostics and shared
base-chain log fetching. Keep ephemeral version handling unchanged, and
bring the shared base-chain helper change forward from the admission PR.

Run the existing unfinalized-account recovery test through explicit
commit and finalize stages: its five-account intent can now fit in a
single v1 transaction. Require both stages to succeed with distinct
signatures, retain the UnfinalizedAccountError and CommitIDError recovery
checks, and verify the final account data.

Validation:
- test_commit_unfinalized_account_recovery_two_stage passed against
  Agave 4.2.0 (one targeted integration test, 31.30 seconds).
- Nightly formatting checks passed for the three affected Rust crates.
- Workflow validation checked all 26 runtime selections, fail-fast,
  the override expression, and the unchanged SBF build pin.
- git diff --check passed.

RedSuite runtime and reader compatibility remain separate follow-up work.

The cloning shard pinned Agave 4.0.3 to retain loader-v4 deployment
coverage, but Magic ATA withdrawals now settle through v1 committor
transactions. Agave 4.0.3 rejects those transactions during RPC
deserialization, leaving both withdrawal tests with a zero base balance.

Run account cloning and Magic ATA tests on the default Agave 4.2 runtime.
Move the program deployment test binary into a cloning_programs shard
using Agave 4.0.3, where loader-v4 remains available. Reuse the existing
cloning binary artifact and validator configurations, prepare mini
programs for the new shard, and preserve SKIP_TESTS=cloning behavior.
All ten existing cloning test binaries remain covered exactly once.

Validation:
- test_magic_ata_transparent_withdrawal passed against Agave 4.2.0 with
  setup-cloning-both (7.06 seconds); local validators stopped afterward.
- cargo check -p test-runner --bin run-tests passed.
- Nightly formatting, workflow runtime selection, test-binary coverage,
  and git diff whitespace checks passed.

No production execution paths or test assertions change. RedSuite is
outside this change; CI provides remaining integration coverage.

The cloning shard on Agave 4.2 leaves the post-delegation SPL transfer
fixture at its initial token balances (200 and 100). The test assigns
the target to DLP before delegation, then relies on a program-account
notification to discover the action. Creating the delegation record
can leave the already DLP-owned target account unchanged.

Transfer one lamport from the fixture payer to the target in the same
transaction as delegation. This ensures an observable target change
with the delegation record and embedded action available atomically.
Keep automatic action discovery and the original token balance checks;
do not replace discovery with an explicit clone or weaken assertions.

Validation on Agave 4.2.0 with setup-cloning-both:
- The exact test_post_delegation_action_executes_spl_token_transfer_100
  reproduced the CI failure before the change (17.47 seconds).
- The same exact test passed after the change (5.36 seconds).
- Nightly formatting for test-cloning and diff whitespace checks passed.

This changes only the integration fixture. Production account handling,
transaction execution, and RedSuite remain unchanged.

Skip the RedSuite build_er job with a job-level false condition. The
run_redsuite job depends on that build, so it is skipped as well without
building artifacts, running scenarios, or publishing reports. Retain the
workflow triggers and original revision pin for a straightforward restore.

The pinned RedSuite revision c0eedc9 uses Agave 4.0.3 in this workflow.
Its commit_width_envelope scenario fails when that runtime cannot
deserialize the validator's v1 commit transactions.

Trying RedSuite e78ea55 locally did not resolve the compatibility gap:
the harness passes MBV_ENGINE__ configuration variables, but this
validator branch still uses the older configuration structure. The ER
exits with an unknown engine field before the scenario can execute.

Keep RedSuite disabled until a compatible harness revision and base
runtime are selected. Re-enable the build job and verify commit scenario
execution and settlement before relying on RedSuite results again.
This is a temporary coverage reduction, not a fix for either mismatch.
Other CI workflows and production validator behavior remain unchanged.

Validation:
- Parsed the workflow YAML and verified the build job's false condition
  and the suite job's dependency on it.
- git diff --cached --check passed.
- Invariant review found no runtime invariant changes in this CI-only diff.
- No Rust tests rerun because no Rust code or test behavior changed.

List the four strategy choices in priority order, explicitly showing which use ALTs and buffer-accounts.

Explain that final task transactions use v1 without ALTs and v0 with ALTs, while buffer preparation and cleanup use a separate v0 path without ALTs. Link task_instruction_offset to this policy and explain how each format carries its compute budget.

Comments only; transaction selection and execution are unchanged. Validated with git diff --check and a review against the existing strategy and preparation paths.

Implement Serialize and SerializableTransaction for the local v1 transaction type. Serialize the cached wire bytes as a tuple so bincode emits them without an extra length prefix, preserving the existing encoding and signed payload.

Submit v1 transactions through send_transaction, reusing its RPC response-signature validation and confirmation behavior. Remove the separate raw-byte sender, inline the now-single-use confirmation helper, and remove the obsolete transaction accessors.

Add the workspace serde dependency to the committor crate and remove the unused base64 dependency from the RPC client. Update both lockfiles without changing dependency versions. The RPC-client source and manifest now match the PR base again.

Validation: nightly formatting passed for both affected crates; the existing serializes_config_before_instruction_headers unit test passed with cargo test --locked; git diff --check passed.

Task account-size estimates do not know the actual sizes of base-chain
accounts and programs used by actions. Enforcing those estimates in the
v1 message can reject otherwise valid intents during account loading.

Set the v1 loaded-account limit explicitly from ComputeBudgetLimits so it
uses the runtime default of 64 MiB, matching the existing v0 behavior.
Omitting the v1 field would mean a zero-byte limit. Remove the estimated
size argument from v1 configuration and reuse the same budget object for
the priority fee, preserving the compute-unit limit and fee calculation.

The maximum limit increases the scheduler's estimated resource cost.
Add a TODO to use a better estimate of actual loaded account and program
data with headroom, allowing a smaller limit without rejecting valid
transactions. This change adds no RPC requests.

Extend the existing two-stage callback integration test with a 2 MiB
transfer destination and assert that it receives the action's lamports.
On Agave 4.1.1, the test failed before the fix with
MaxLoadedAccountsDataSizeExceeded and passed afterward, including the
callbacks from both stages. Nightly formatting checks passed.